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(54) Generating and processing computer programs. 

(57) Method and means are described which pro- 
vide a way for an application program to be 
generated to include dependency control 
blocks which indicate which support programs 
must be initialized in the run-time support envi- 
ronment prior to the application program's in- 
itialization and which must be terminated after 
its termination. Since support programs may be 
dependent on each other, a topological sort is 
performed to determine an order in which the 
support programs can be initialized so that no 
routine is initialized before all of its prerequis- 
ites are initialized. The initialization order is 
saved, so that following the execution of the 
program, termination can be performed in the 
reverse order. 
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Technical Field 

The present invention relates to generating and processing computer programs. 

Various high level languages are in wide use for computer programming, e.g., C, COBOL, FORTRAN, PL/I, 

5 PASCAL, etc. Computer-programs may be written in morethan one of these languages. Execution ofprograms_ 
written in these languages normally requires that language specific run-time support code be present and ini- 
tialized to enable the code produced by the respective compilers to function correctly. It is desirable to allow 
for the language specific run-time support code to be written in multiple languages, but this presents special 
problems. Termination ordering also presents similar problems. 

10 During initialization and termination of a multi-language application program, language specific initializa- 

tion and termination routines are called for each language in the application. When the language specific rou- 
tine for a particular language requires support provided by a second language then the second language's 
support must be initialized before the first language's support is initialized and terminated only after the first 
language's support has been terminated. 

15 The idea of ordering based on dependencies is known. Knuth, for example, describes the problem in The 

Art of Computer Programming , Vol. 1, Addison-Wesley, 1975, pages 258-265. Knuth describes the problem 
of topological sorting of a set on which a partial ordering is defined. The goal is to find a linear sequence of 
the members of the set such that any item in the sequence will precede another in the sequence if the one is 
defined to precede the other in the partial ordering. Knuth describes an algorithm for topological sorting. 

20 The problem of initialization ordering is related to topological sorting. The dependency that one language 

has upon the initialization of another defines a partial ordering between the languages. The problem is to find 
an order to initialize languages in a multi-language application so that for any language in the application, all 
languages that it depends upon are initialized by the time it must be initialized. Termination can then be per- 
formed in the reverse order. 

25 It is also possible for programs to have dependencies on support programs which are unrelated to language 

support as such. Dependency on a debugging program would be an example of this. 

It is conventional in the computer science field to use control blocks (sometimes called headers) containing 
non-executable code to convey information needed to execute a program. Control blocks which give initial in- 
formation about a program are sometimes called program headers. 

30 The term "application program" (or simply "application") will be used to include both end-user developed 

computer programs and computer programs which are sometimes called system programs, such as compilers. 
For convenience, the term "program" will be used to include routines or modules which in other contexts might 
not be considered to be programs. Thus, language specific run-time support routines will be called programs 
even though they may be inherently incapable of independent execution. 

35 According to the invention there is provided a method of generating object code for inclusion in a computer 

program having executable object code comprising the steps of: forming a dependency control block (DCB) 
object code having a selected symbolic name; writing in the DCB object code data representative of prereq- 
uisite programs on which the executable object code is dependent: and storing the DCB object code together 
with the executable object code: thereby, creating first object code. 

40 There is further provided a system for generating object code for a computer program having executable 

object code comprising: means for forming a dependency control block (DCB) object code having a selected 
symbolic name: means for writing in the DCB object code data representative of prerequisite programs on which 
the executable object code is dependent: and means for storing the DCB object code together with the execu- 
table object code: whereby first object code can be created. 

45 The control blocks may then be used to indicate which support programs must be initialized in the run- 

time support environment prior to the application program's initialization, permitting the initialisation and ter- 
mination of prerequisite programs, including language specific support routines, for a single or multi-language 
application that will satisfy the dependencies. In a embodiment to be described below, a set of control blocks 
is defined which is associated with an application program. These control blocks contain information which 

so allows a common run-time initialization routine to ascertain the prerequisites upon which the application de- 
pends. The object code for application programs is generated to include object code forming one or more de- 
pendency control blocks (DCBs) together with executable object code produced by a compiler or assembler. 
Each DCB can contain information specific to the compiler, assembler or other program which generated as- 
sociated executable object code. The DCB lists the prerequisite programs on which the executable object code 

55 depends. The object code for the DCB is preferably given a symbolic name for subsequent reference by a link- 
age editor. The DCBs may be implicitly associated with a language or other support program, so that there is 
no need to explicitly declare the associated language in its dependency list. The executable object code with 
its DCBs is preferably linked together with object code produced by other programs with their associated DCBs. 

2 
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The initialization of the application program requires reading all of the DCBs included in the application pro- 
gram to determine all prerequisite language support and other routines needed by the application The order 
of initialization of prerequisite routines is determined by performing a topological sort using the inter-depend- 
ences to obtain an order in which initialization can occur such that no routine is initialized before all of its ore- 
requisites are initialized. The initialization order is saved, so that following the execution of the application pro- 
gram termination can be performed in the reverse order. 

The run-time environment initialization program must be able to locate all of the DCBs included in an ap- 
plication program This is conveniently effected in the preferred embodiment by including in a program header 
the address of a language list which in turn contains the addresses of all of the DCBs 

In order that the invention may be well understood, a embodiment thereof will now be described with ref- 
erence to the accompanying drawings, in which:- 

tr . h?" 9 wiJim StrateS Pr ° CeSS ° f preparin 9 application program object code containing a dependency con- 

vTOI DIOCK (Lit— »d). 

Figure 2 illustrates the process of forming a DCB. 

Figure 3 illustrates the process of forming a language list referencing all possible DCBs 
Figure 4 illustrates the process of initializing the support programs for a program containing DCBs 
DCBs 9Ure 5 ,l,UStrateS thS structure of a s y stem for initializing the support programs for a program containing 
Figure 6 illustrates the structure of a system for creating DCBs and combining them with executable object 



20 code 



The invention is preferably implemented as a part of a larger common run-time environment, which will 
be called the Common Execution Environment (CEE) for system and application programs which may be writ- 
en m multiple H.gh-Level Languages (HLL). The invention is suitable for use on any size computer from main- 
frames to personal computers. CEE consists of common services which can be shared by all programs regard- 
less of the language in which they are written. The system library available to the user also includes language 
specific : support routines (LSRs), and other support programs which collectively will be called support pro- 
grams. The inventions independent of operating systems and programming languages and can be applied to 
any multi-language run-time environment. 

When an application begins executing, it must first initialize CEE before it can use any of the CEE provided 
services. This can be effected through any standard means of transferring program control. In the detailed 
embodiment it is done by calling an arbitrary external symbolic label reserved for use by CEE and passing 
information in registers which allows CEE to find the program header. When the application completes it in- 
vokes the termination service of CEE in a similar manner. When CEE begins, it first initializes the common 
services, then, for each language in the application, it determines the LSR for that language Only the LSRs 
required by the application are initialized. Similarly, during termination, CEE first terminates the LSRs and 
then the common services. 

An LSR can be written in any language within certain restrictions. The LSRs can take advantage of common 
CEE services, since they are initialized before language specific components. But the LSR cannot in general 
take advantage of features of the language in which it is written unless that language is already initialized For 
example, ,f the language specific support routines for COBOL were written in C, then initialization for applica- 
tions that include COBOL routines would have to include initializing the C specific support routines first The 
prior art does not teach a way to communicate this type of dependency to a common initialization program 
Similarly requir.ng debugging support might require that LSRs be initialized to support the code in the debug- 

To solve this problem a means is provided for compilers for each language used in an application to indicate 
which other LSRs and support routines must be initialized prior to its initialization. The full list of support rou- 
tines needed by an application is determined along with each one's dependencies, then a topological sorting 
method « used to determine an initialization order that will satisfy the dependencies as indicated by each con- 
trol block. 

For each language required by a multi-language application, a language specific control block is statically 
bound with the application. These can be accessed by CEE during initialization by way of the parameters 
passed to CEE initialization routine. Each language specific component in CEE is identified by a unique mem- 
ber identifier. Within each of the language specific control blocks is a table of member identifiers indicating 
which support programs must be initialized before that memb r can be initialized. Thus, during initialization 

can det ermine the dependencies between all the languages in the application. 

Figure 1 shows the process of preparing object code containing a control block which lists the programs 
w" ^InVm n ^ xeCUtable ° bjeCt C ° de is de P endent - ™s control block will be called the dependency control 
block (DCB). The support code library 115 consists of executable object code for language specific support 
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routines or other programs which might be typically stored on non-volatile storage, e.g., disk drives, for repeat- 
ed subsequent use. The language list 116, which is shown in detail in Table 4, is used to create a table of ad- 
dresses for all of the DCBs contained in the final program 118. Only one DCB is shown and is labelled DCB- 
xJ17,.butJn_practiceJhere„will be_muJU 

5 using standard compilers and/or assemblers 111. The user uses the compilers and/or assemblers to create 
custom object code with an associated program header 112. Ageneral purpose program header may be used 
or a program header specific to the compiler may be used, but in either case it is typically pre-compiled and 
included in the library. The user code is then combined with executable code from the library along with the 
language list and the appropriate DCBs through the use of a standard linkage editor 114 to produce the user's 

10 program 118 which consists of linked executable object code, the non-executable code of the program header, 
the language list, and the DCBs! The program header contains a pointer to the language list which in turn has 
a pointer to the DCB. 

Figure 2 describes the steps of preparing executable object code and an associated DCB. Compiling the 
executable object code 121 is done according to the prior art practice. The forming of the DCB 122 is achieved 

15 by compiling or assembling source code, such as is shown in Table 2, to produce an object module which has 
an external symbolic name and contains data representative of the prerequisite programs on which the execu- 
table object code is dependent. Since it will normally be the case that the executable code and the DCB will 
be part of a collection of programs which will be used repeatedly over a long period of time, they should be 
stored 123 together on non-volatile storage such as a disk drive. If the information about the dependencies 

20 of the executable object code are known prior to compilation, the DCB may be created first. 

The language list acts to create a list of all of the DCBs that ultimately are combined into a single program. 
Any mechanism which allows the CEE to locate all of the DCBs will work. Applicants' Detailed embodiment 
described herein uses a language list which is a separate object module. In another embodiment the function 
of the language list could be combined into the program header, for example. Figure 3 shows the process of 

25 creating the language list. Source code for the language list, such as is shown in Table 4, is prepared 126, 
compiled or assembled 127 and stored for repeated subsequent use 128. 

After CEE has initialized the common services component, it initializes all language specific components 
or members in the application using the method described in pseudo-code in Table 1. By virtue of the loop in 
lines 10-14 all required support programs for the application will be initialized. By virtue of the first when clause 

30 17, a member support program is not initialized until all members it depends upon are initialized. By virtue of 
the second when clause 25, if there is a member with a dependency directly or indirectly upon itself (a circular 
dependency), it will be detected. 

Satisfying termination dependencies is a similar problem. A support program must terminate before any 
support program that it depends upon. To solve this problem, the initialization order is saved in memory for 

35 use at termination time. The support programs are terminated in the reverse order from initialization. 
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10 mark all members uninitialised 
.5 : 1 . 1 for ? a <~ h m?JDber,_.M, re_quired..by the application 

12 call Initialize Member (M) 

13 end for 

14 exit 

/* Initialize Member logic. */ 

15 Initialize Member (M) 

16 select 

17 when M is uninitialised 

18 mark M initializing 

19 for each member M 1 on which M depends 

20 call Initialize Member ( M ' ) 

21 end for 

22 initialize M 

23 mark. M initialized 

24 record the order in which M was initialized 

25 when M is initializing 

2 6 handle error: cyclic dependency 

27 when M is initialized 

28 nop 
25 29 end select 

30 return 

31 end 

Table 1 

30 



The form of the control block which lists dependencies is not critical. Any format may be substituted that 
provides the same dependency information. In the detailed embodiment described herein in detail, the control 

35 block is statically linked into the application, but in an alternative embodiment, it may be provided dynamically 
and read at execution time. 

The particular algorithm used to determine the order for member initialization is not critical so long as it 
meets the requirement of not initializing any program before all of its dependencies have been initialized. Any 
algorithm that will perform a topological sort will work. Languages may either be initialized as each member 

40 is placed in final sorted order, or the members may be first sorted and then initialized in their sorted order. 
What is important is that the members be initialized in topological sorted order. 

In the detailed embodiment the members to be initialized are communicated to the initializing routine 
through a control block which contains non-executable code. Table 2 shows an example, in standard IBM as- 
sembler language, of a DCB listing three dependencies. At line 105 a unique four character string is used to 

45 identify the particular compiler or other program to which the DCB belongs. This association implicitly identi- 
fies the specific support routine for the compiler. If, for example, the CEESG004 DCB has been assigned to 
the REXX compiler, then CEE automatically knows that the LSR for REXX, if any exists, must be initialized 
before the application containing this DCB can be executed. The total number of dependencies is listed as 
three at line 108. The dependencies are listed-at lines 113-115 as coded integers 1,2, and 5. These numbers 

50 are arbitrarily assigned to correspond to certain programs or language specific components. Thus, "1" might 
correspond to C specific support, "2" to FORTRAN specific support and "5" to COBOL specific support. It is 
essential to the functioning of the described embodiment that a predetermined list of these codes be available 
so that each programmer creating a DCB will know what numerical codes to put in the DCB to correct ly indicate 
the dependencies. An alternative embodiment could use codes that are self-defining by, for example, putting 

55 character strings in the list which give the full name of the program so that the initialization program can unique- 
ly identify the program which it needs to load without further extrinsic information. Self-defining codes also 
have the advantage that they can be dynamically built and updated. 
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************* 


************** 
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106 




DC 
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length of this csect 


107. 




DC 
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version 


108 




DC 


H'3' 


Number of dependent member IDs 


109 




DC 


Y( DEPIDS-CEESG004) 


Offset to the first dep. member 


ID 
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DC 


XL4 1 0 ' 


Reserved for member use 


111 




DC 


XI^'O 1 


Reserved for member use 


112 


DEPIDS 


EQU 


* . 


List of ids dependent upon 


113 




DC. 


FL1 ' 1 ■ 


Program assigned code ' 1' 


114 




DC . 


FL1 '2* 


Program assigned code ! 2 f 


115 




DC 


FLl'S 1 


Program assigned code '5' 


116 




END 
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Table 2 



25 Each program requesting initialization must have a program header such as the one listed in Table 3. Any 

format of header will work. The only piece of information in this header used in the invention is the address 
of CEELLIST at x+40 which is the language list. 
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0+44 



START 
START 
START 



000000 
000004 
000008 
O0O0OC 

00000E 

000012 
000018 
00O01C 
000020 



x 

x+00 
x+10 
x+14 
x+16 

x+18 - 3C 
x+40 
showing 



17 



CSECT . ... 

AMODE - ANY- - - ^ v^^--^:-^ - 
RMODE ANY 
NOP 0 
NOP y 

STM 14,12,12(13) Save caller regs 
BALR 3,0 
USING *,3 

3 AROUND Branch around signature 

... unrelated data 

Point to PLIST 
Eye-catcher 
Reserved 



AROUND 



DC 
DC 
DC 
EQU 



A (PLIST) 
CL8 ! START * 
H'0' 



member code 



PLIST 



DS 

CXD 

DC 

DC 

DC 



OF 



H l -1' 

AL2(PLI STOLEN) 
A(CEELLIST) 



PL I STOLEN EQU *- PLIST 
Table 3 



unrelated data 

unrelated data 

List of weak externals 

. . , languages in load module 

Length of Parm List 



35 

The format of the CEELLIST language list is shown in Table 4. The order of the entries in the language 
list in the detailed embodiment corresponds to the codes assigned for use in the DCBs, but the order is un- 
important. CEELLIST can contain entries for programs other than language specific support routines. In the 

40 sample list in Table 4, the sixth entry in the list corresponds to a debugging program. Entries do not need to 
be assigned at all; thus, entry one is listed as unassigned. The DCB shown in Table 2 is labelled CEESG004 
and corresponds to the fifth entry in the list. When DCB's with the proper labels are linked into a module with 
.CEEBLLSTthe addresses of those DCB's present will be placed in the list by conventional linkage software. 
CEE will find zeroes in the list for all DCBs not present in the module. Using the DCB address CEE can then 

45 easily find the list of dependency codes and mark those requiring initialization for input into the topological 
sorting routine of Table 1. The "WXTRN" keyword is conventionally supported by assemblers and linkage edi- 
tors for computers in IBM's System/370 family and is used to indicate a weak external reference. The linkage 
editor will attempt to link these external references, but will only issue a warning if they are not found. 

50 
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08 


comDiler- 1 
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DC 


Ay Cc.c.bvjUUy ) 


09 


compiler-m 
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DC 
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10 


compiler-n 


WXTRN 


CEESG011 






DC 


A(CEESGOll) 


11 


Debugger 


WXTRN 


CEESG012 






DC 


A(CEESG012) 


12 


compiler-o 


WXTRN 


CEESG013 






DC 


A(CEESG013) 


13 


compiler-p 


WXTRN 


CEESG014 






DC 


A(CEESG014) 


14 


compiler-q 


WXTRN 


CEESG015 






DC 


A(CEESG015) 


15 


assembler 


WXTRN 


CEESG016 






DC 


A(CEESG016) 


16 


compiler -r 


DC 


A(0) 


Dummy entry nru 


DS 


OD 


This boundary 



LLISTEND DC A(0) 
END 



It is needed to save processing time 

CEE is being initialized. 
MARK THE END OF LIST 



Table 4 



55 Figure 4 shows the steps executed by CEE in initializing an application program containing DCBs. First, 

all of the DCBs must be located and a list of all prerequisites is made 131. In the detailed embodiment this 
step requires first reading the program header to find the address of the language list then using the language 
list to determine the number of DCBs present in the program and the location of each one. The topological 
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sort is performed 132 to find an order in which initialization can occur without violating any dependency rela- 
tionship. The support programs are initialized in the order determined by the topological sort and the order is 
saved for later use 133. Control is returned to the application program 134. When its execution is completed, 
the application returns control to CEE to allow termination of the support programs. Each support program 

5 must have a defined mechanism for allowing CEE to initialize and terminate it.-This is preferably done through 

a standard call and return mechanism. CEE terminates the support programs in the reverse order from the 
initialization order 135. 

Figure 5 is a block diagram showing the overall structure and inter-relationships of the functional units re- 
quired to initialize a program using DCBs. The locating and reading means 151 passes an unordered list of 
io support programs to the topological sorting means 152. The generated sorted list is stored in memory 153, 
e.g., RAM or disk. The initialization means 154 uses the sorted list to determine which support programs are 
to be initialized from the library 115. The library is simply the collection of support programs which will typically 
be stored on disk. Control begins with the application program which must call CEE to activate the sequence. 
After initialization the application program regains control 155 until it is ready to request termination. The ter- 
15 mination means 156 must have access to the previously stored sorted list. 

Figure 6 is a block diagram of the functional units required to generate a DCB. A list of codes for the support 
programs 1 61 is used by the DCB generator 1 62 in conjunction with the executable object code 1 64 to generate 
the DCB 163 which encodes the dependencies. The DCB is then stored together with executable object code 
on non-volatile storage for subsequent use 165. 
20 Some advantages that the invention has over prior art techniques are: 

Components of a language runtime environment may themselves be written in a high level language 
or even multiple languages. 

Only those language specific components of the runtime environment that are necessary for the exe- 
cution of the application need be initialized thereby saving execution time. 
25 When a routine is called in an application, it need not first check whether its language specific support 

is initialized, also saving execution time. : 

The control block usage requires minimal or no changes to compilers. 
Using the foregoing specifications the invention may be implemented using standard programming tech- 
niques. The resulting program(s) may be stored on disk, diskettes, memory cards, ROM or any other memory 
30 device. For execution the program may be copied into the RAM of the computer. One skilled in the art of com- 
puter science will easily be able to combine the software created as described wit h appropriate general purpose 
or special purpose computer hardware to create a system. While the detailed embodiment of the present in- 
vention has been illustrated in detail, it should be apparent that modifications and adaptations to that embodi- 
ment may occur to one skilled in the art without departing from the scope of the present invention as set forth 
35 in the following claims. 



Claims 



40 1. A method of generating object code for inclusion in a computer program having executable object code 
comprising the steps of: 

(a) forming a dependency control block (DCB) object code having a selected symbolic name; 

(b) writing in the DCB object code data representative of prerequisite programs on which the executable 
object code is dependent; and 

45 (c) storing the DCB object code together with the executable object code; 

thereby, creating first object code. ■ 

2. The method of claim 1 further comprising the step of: 

linking the first object code to a language list object code containing a plurality of external refer- 
so ences to symbolic names, including the selected symbolic name, to place the address of the DCB object 
code in the language list object code; 
thereby, forming second object code. 

3. The method of claim 2 further comprising the step of linking first and second object codes to a program 
55 header object code referencing a symbolic name for the language list, to place the address of the language 

list into the program header object code. 

4. A method of processing a computer program comprising the steps of: 
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(a) reading a plurality of dependency control blocks (DCBs) specifying prerequisite support programs; 
and 

(b) initializing the support programs in an order such that no support program is initialized until all of 
its prerequisite support programs have been initialized. 



>. The method of claim 4 wherein the initializing step further includes the steps of: 

(a) selecting a prerequisite support program M; 

(b) if M is uninitialised, then marking M as initializing; 

(c) for each prerequisite support program M' on which M depends recursively executing the method 
10 beginning at step (b) using M' as M; 

(d) initializing M; 

(e) marking M as initialized; and 

(0 returning to step (c) at the point of recursion, if in a recursion. 



The method of claim 4 further including the step of recording an initialization order of the prerequisite 
support programs for use during termination. 

7. The method of claim 6 further including the step of terminating the prerequisite support programs in a 
reverse order from the initialization order after the computer program has completed execution. 

20 8. The method of clajm 4 including the preparatory step of reading a program header to locate the DCB. 

9. The method of claim 4 including the preparatory steps of: 

(a) reading the address of a language list object code from a program header object code; and 

(b) reading the addresses of the DCBs from a language list object code. 

25 

10. A system for generating object code for a computer program having executable object code comprising: 

(a) means for forming a dependency control block (DCB) object code having a selected symbolic name; 

(b) means for writing in the DCB object code data representative of prerequisite programs on which 
the executable object code is dependent; and 

30 (c) means for storing the DCB object code together with the executable object code; 

whereby first object code can be created. 

11. The system of claim 10 further comprising means for linking the first object code to a language list object 
code containing a plurality of external references to symbolic names, including the selected symbolic 
name, to form second object code containing a DCB and a language list object code which contains the 
address of the DCB. 



12. The system of claim 11 further comprising means for linking the second object code to a program header 
object code referencing a symbolic name for the language list, to place the address of the language list 
into the program header object code. 

13. A system for processing a computer program comprising: 

(a) means for reading a plurality of dependency control blocks (DCBs) specifying prerequisite support 
programs; and 

(b) means for initializing the support programs in an order such that no support program is initialized 
until all of its prerequisite support programs have been initialized. 

14. The system of claim 13 wherein the reading means further includes means for reading numeric or char- 
acter codes which uniquely identify the prerequisite programs. 

50 15. The system of claim 13 further including means for recording an initialization order of the prerequisite pro- 
grams for use during termination. 

16. The system of claim 15 further including means for terminating the prerequisite programs in a reverse 
order from the initialization order after the computer program has completed execution. 

55 

17. The system of claim 13 further including means for reading a program header to locate the DCB. 

18. The system of claim 13 further including: 
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(a) means for reading the address of a language list object code from a program header object code; 
and 

(b) means for reading the addresses of the DCBs from a language list object code. 
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